Lambda the Ultimate

In connection with the recent discussion concerning how people think about programming, I thought it might be worthwhile to revisit some of E. Dijkstra's writings on the subject.

From EWD854: The fruits of misunderstanding:

I think anthropomorphism is worst of all. I have now seen programs "trying to do things", "wanting to do things", "believing things to be true", "knowing things" etc. Don't be so naive as to believe that this use of language is harmless. It invites the programmer to identify himself with the execution of the program and almost forces upon him the use of operational semantics.

and:

And now we have the fad of making all sorts of systems and their components "intelligent" or "smart". It often boils down to designing a woolly man-machine interface that makes the machine as unlike a computer as possible: the computer's greatest strength—the efficient embodiment of a formal system—has disguised at great cost.

and:

Another analogy that did not work was pushed when the term "software engineering" was invented. The competent programmer's output can be viewed as that of an engineer: a non-trivial reliable mechanism but there the analogy stops...

From EWD1036: On the cruelty of really teaching computing science (html):

It is the most common way of trying to cope with novelty: by means of metaphors and analogies we try to link the new to the old, the novel to the familiar... Coping with radical novelty requires an orthogonal method... one has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate... Coming to grips with a radical novelty amounts ot creating and learning a new foreign tongue that can not be translated into one's mother tongue. (Any one who has learned quantum mechanics knows what I am talking about.)

and:

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash [sic]: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot".

and:

We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation... My next linguistical suggestion is mor rigorous. It is to fight the "if-this-guy-wants-to-talk-to-that-guy" syndrome: never refer to parts of programs or pieces of equipment in anthropomorphic terminology...

and finally there is the now-classic example (a domino-tiling problem) of why "operational reasoning is a tremendous waste of mental effort."

In debates over merits of programming paradigms, languages, and tools, often the way ordinary humans think is cited. For example, some opinions dismiss non-imperative programming "because people think in terms of states", or non-object-oriented programming "because people think in terms of manipulating objects".

I think this is all very well. Ordinary people also fear blood and gore. Can you imagine an "opinion leader" in medical science saying "never cut open the body of appendicitis patients because it would be tough to doctors"? Medical treatments are assessed based on benefit and harm to patients, not comfort of doctors. Medical students are required to learn to face blood and gore, or quit.

The "natural" or "common" argument is never brought up in professions such as medicine and surgery, law, accounting, and engineering whenever there are debates over methodologies and training. It is not ordinary people's nature to be rigorous, analytic, quantitative, formal, rational, calm, objective, impartial, ... The professions do not give in to human nature; quite on the contrary, apprentices are trained for years against human nature, and those who fail to change are weeded out.

There are professions and professional training because the way of common people is deficient.

If common people can think of nothing other than states and objects, perhaps programmers should grow out of it.

(Also posted as
http://slashdot.org/~Albert%20Y.C.%20Lai/journal/83868
and in comp.lang.functional under the same title.)

hi,

my google-fu is failing me. there's a discussion from way back where frank discusses what types are with someone who, maybe incorrectly, i think is involved with game design. this other person argued type theory was based on sets (i can't remember the full argument), frank that category theory was a better approach.

i realise that this could describe an awful lot of discussions, but this was a particularly detailed exchange and it was fairly early on in the site's history.

does this ring bells with anyone else? any pointers? thanks.

Following on the heels of this year's ICFP Programming Contest, Ant Wars is a competitive programming web game where competitors code finite state machine ant brains to guide colonies of ants. Two species compete for food in a simulation; the ant with the most food at the end winning.

The programming is currently done in an s-expression based high level language, compiled to a simple bytecode using SISC. Many intriguing behaviors have already arisen, including a running arms race between two competitors.

Phil Greenspun has an amusing anecdote of his troubles with MIT Scheme, from, I guess, around 1990, and including an unwise declaration from Gerald Sussmann. Not terribly conclusive, but I'd like to collect similar anecdotes, if anyone has some. Via lemonodor.

[edit: CL <-- CLisp following Pascal's comment in thread]

Here's a spectacular paper by Oleg Kiselyov and Chung-chieh Shan which describes a method of faking dependent types in Haskell using type classes.

McBride mentions that, with all the tricks, the programmer still must decide if data belong in compile-time or run-time terms. "The barrier represented by :: has not been broken, nor is it likely to be in the near future." If our reflect and especially reify functions have not broken the barrier, they at least dug a tunnel underneath.

(Mentioned yesterday by Dave Menendez in the Apple Flunks... thread, but I thought the paper merited a discussion of its own)

If any language designers are interested, I am offering to host forums dedicated to their language at http://www.heron-forums.com and give them moderator privileges.

For any other who happens to really love programming language oriented weblogs, I might as well plug my own at the same time at http://www.heron-centric.com which focuses on the Heron programming language.

Article

Reflection in logic, functional and object-oriented programming: a Short Comparative Study

Abstract: Reflection is a wide-ranging concept that has been studied independently in many different areas of science in general, and computer science in particular. Even in the sub-area of programming languages, it has been applied to different paradigms, especially the logic, functional and objectoriented ones. Partly because of different past influences, but also because researchers in these communities scarcely talk to each others, concepts have evolved separately...

Quite an old paper, but pretty interesting. And yes, it mentions reflective towers and Frege :)

A Debugging Environment for Lazy Functional Languages

Abstract: This paper describes a new approach for debugging lazy functional languages. It rests on the fact that a functional program is the transformation of an expression; one debugs a program by investigating the syntactic form of the expression and by stopping the reduction process at given points. We show what problems are involved and our approach to solving them in a prototype implementation.

I remember there was a discussion of difficulties with lazy FPL debugging, and I didn't find a reference to this paper on LtU, so...

PS: beware, "a new approach" means around 96-99 :)